Add experimental flex-operator Helm chart - #422

Summary

Adds an experimental Helm chart, charts/flex-operator, that packages the
Unbounded operator (unbounded-operator v0.8.0, the version pinned in the
getting-started guide and the AKS RP Flex Node E2E). The goal is to let AKS
install, upgrade and remove the operator as a managed cluster extension instead
of customers running kubectl unbounded install themselves (Flex operator
managed extension PRD).

What's in it

• charts/flex-operator: ServiceAccount, ConfigMap, ClusterRole/Binding and
  Deployment mirroring upstream deploy/unbounded-operator. Must be installed
  into unbounded-system.
• Optional sites / sitePeering values: a post-install/post-upgrade Job
  applies Site and SitePeering objects once the operator has established its
  CRDs (same shape as the AKS RP E2E). Off by default.
• hack/flex-operator/upstream-v0.8.0 + compare_upstream.py, and
  make chart-check: lints the chart and diffs its render against the upstream
  manifests, so drift is caught when the pinned release changes.

Intended differences from upstream: Namespace comes from the release,
imagePullPolicy: IfNotPresent (pinned tag), config-hash computed from the
rendered ConfigMap.

Validation

• make chart-check, make docs-check, make build pass; GitHub CI green on the first push.
• AKS 1.36 (Azure CNI), direct helm install: operator Ready in ~15s and
  bootstraps 12 Unbounded CRDs; no Sites, cluster CNI untouched.
• Same chart installed through AKS Extension Manager with an internal,
  customer-hidden test extension type: az k8s-extension create, config
  update (operator.apiServerEndpoint, rolls the operator) and delete all
  succeed.
• Chart refuses to install over an operator created by kubectl unbounded install
  (tested live; the existing operator is left untouched).
• End to end on a --network-plugin none AKS 1.36.5 cluster:
  • helm install with sites (cluster + flex-site) and a SitePeering: the
    hook Job applied them, the operator installed Unbounded-Net, Machina,
    Gantry and token-refresher, and the system node went Ready on site cluster.
  • FlexNodes pool + Ubuntu 24.04 Azure VM bootstrapped with
    scripts/bootstrap.sh (agent v0.2.0, MSI): node Ready on site
    flex-site, pool type FlexNodes.
  • Pod on the flex node got a flex pod-CIDR IP; a pod on the AKS node reached
    it by pod IP and by Service DNS; the flex pod reached the API server via the
    service IP; kubectl logs against the flex pod works.
• Upgrade with a flex node attached: chart with operator v0.8.0 → v0.18.0
  (RBAC synced from upstream). Operator and all components (Unbounded-Net,
  Machina, Gantry, token-refresher) rolled to v0.18.0, both nodes stayed
  Ready, and 120/120 cross-node requests over ~8 minutes succeeded.

E2E found and fixed two chart bugs (second commit): the Sites Job used a shell
that the distroless kubectl image doesn't have, and it set components.net,
which the v1alpha3 Site schema rejects. Sites now match kubectl unbounded site init.

Open questions for reviewers

1. Cleanup: the operator owns its CRDs, so uninstall/extension delete leaves
   12 CRDs, any Sites and component workloads. Should the extension remove them,
   or should AKS block disable while Flex pools/Sites exist (as the PRD suggests)?
2. Sites: keep the optional hook (now validated end to end), or leave Sites
   to kubectl unbounded site init/AKS RP?
3. Version: pin v0.8.0 (matches docs/labs) or move the chart to v0.18.0
   (validated upgrade path above)?
4. Adoption: how to detect/adopt an operator already installed by the CLI.
5. Home: does this belong here or upstream in Azure/unbounded?
6. Images: production needs the operator and every component mirrored under
   one registry prefix (MCR).

🤖 Generated with Claude Code